Kodosky concerns the modeling of electronic instruments. These are totally 
different. 

• No suggestion or motivation has been shown to combine the teachings of 
Kodosky with those of Marshall, nor has any expectation of success been 
shown with regard to such a combination. 

• Kodosky fails, either alone or in combination with Marshall, to teach all limi- 
tations of the present claims. Specifically, 

o Kodosky teaches the processing of objects (virtual laboratory instruments) 
that are specified in a processor-specific manner, that is, they are not 
specified independently of the processor(s) that will act on them; and 

o Marshall teaches financial instruments represented by visual "metaphors" 
in a virtual world - while Marshall involves processing events relative to 
those "metaphors," it does not teach representing an instrument as an 
event stream; i.e., Marshall lacks an "event representation" of any finan- 
cial instrument. 

The above points will be discussed in relation to claim 21, which is the base claim 
of all of the currently pending claims. For the Examiner's reference, a copy of claim 21 
as previously amended is included in the sheet attached at the end of this paper. 

1. Kodosky is Nonanalogous 

Kodosky relates to the "Lab VIEW" system, a graphical development environment 
for scientific and engineering test, measurement and control applications, which uses 
"virtual instrumentation." What Kodosky means by "instruments" are electronic instru- 
ments, such as voltmeters, frequency meters, oscilloscopes, temperature gauges, etc. The 
present application, of course, concerns the modeling of financial instruments, such as 
financial options, puts, calls, derivatives, etc. These are documents containing a legal 
right or obligation of a contractual nature. Needless to say, laboratory "instruments" are 
far afield from financial instruments. The classifications are indicative: the present in- 
vention is currently classified in class/subclass 705/35 (financial data processing), 
whereas Kodosky is classified in classes and subclasses concerned with iconic graphic 
user interfaces (715/846; 715/835), a subject not mentioned in the present application. 
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According to MPEP 2141.01(a), "[i]n order to rely on a reference as a basis for 
rejection of an applicant's invention, a reference must either be in the field of applicant's 
endeavor, or if not, then be reasonably pertinent to the particular problem with which the 
inventor was concerned." 

Kodosky is certainly not in Applicant's field of endeavor. Nor, as we will dis- 
cuss, is Kodosky "reasonably pertinent" to the problem addressed in claim 21. 

2. No Suggestion or Motivation to Combine 

A prima facie case of obviousness requires "some suggestion or motivation, either 
in the references themselves or in the knowledge generally available to one of ordinary 
skill in the art, to modify the reference or to combine reference teachings." MPEP 2143. 
There must also be a reasonable expectation of success in such a proposed combination. 
Id. 

The fact that one of the cited references comes from such a remote field makes it 
even more important for the Examiner to have provided a basis for the conclusion that it 
would have been obvious to a person of ordinary skill in the art to have combined its 
teachings with those of another reference. In support of the rejection, the Examiner pro- 
poses an analogy between, on the one hand, processing by acting upon the "event rep- 
resentation" of a financial instrument (comprised of payments, option exercises, etc.), 
and, on the other hand, the processing of executable code representing components of 
electronic instruments in a laboratory instrumentation system. In addition to the fact 
(about to be discussed below) that newly cited reference describes processing that is fun- 
damentally incompatible with the processing defined in the present invention, it also ap- 
pears that the Examiner has not cited any rationale for the proposed combination, even if 
the reference in question had any relevance, which it does not. In particular, the Exam- 
iner has articulated no reason why a person of ordinary skill in the field of financial sys- 
tems would be motivated to look into the field of laboratory instrumentation in order to 
come up with suggestions for processing contract rights, or to have any basis for expect- 
ing success based on such a combination. 

MPEP 2143.01 states: "A statement that modifications of the prior art to meet the 
claimed invention would have been 'well within the ordinary skill of the art at the time 
the invention was made' is not sufficient to establish a prima facie case of obviousness 
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without some objective reason to combine the teachings of the references." Here, in a 
similar form of rejection, the Examiner recited simply that "it would have been obvious 
for an artisan of ordinary skill in the art to integrate the features of Kodosky into Mar- 
shall. . ." (Action at page 4) - without providing any reason why it would have been obvi- 
ous to make such a combination. Such a conclusory recitation is not sufficient to support 
a rejection under 35 U.S.C. § 103 (a). 

3. Kodosky is Irrelevant in any Event 

(a) Lack of "Independence." Claim 21 contains the limitation "wherein said rep- 
resentation [i.e., the "event representation of the instrument] is specified independently 
from said at least one processor." Kodosky discloses nothing of the sort. 

First, the rejection necessarily presupposes that the "event representation" of a fi- 
nancial instrument can be compared, with regard to its processing, to the "executable 
code functions" created in Kodosky to implement components of electronic instruments. 
Applicant believes this is a strained analogy because the objects in question are so differ- 
ent. Nevertheless, even accepting such an analogy for purposes of argument, the "proc- 
essing" that Kodosky performs on these "executable code functions" is simply not inde- 
pendent from the specification of the executable code elements. This rules out any appli- 
cability of Kodosky to claim 21. 

It is clear, in fact, that the executable code elements of Kodosky are specific to the 
processor employed to process them. This can be readily seen from the manner of their 
creation, which is via clicking on predefined functions provided in GUI menu selections 
(see Fig. 33 of Kodosky). The pre-defined functions are in turn implementations of a 
specified list of primitives supported by the processor, including "sequence," "condi- 
tional," "iterative loop," "indefinite loop," etc. - as described at length in connection with 
Figs. 8-18 of Kodosky, see col. 9, line 65 - col. 10, line 9, and col. 10, line 54 - col. 13, 
line 66. Every "executable code function" to be "processed" in accordance with Kodosky 
must be specified in advance in accordance with the provided processor-specific func- 
tions, as shown at col. 24, lines 30-66 of Kodosky. 

Furthermore, as explained in Applicant's previous submission (March 2, 2004), 
the "independence" aspect of claim 21 implies the ability to have a "many-to-many" rela- 
tionship between instruments and processors. This feature permits there to be a plurality 
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of (or different) processors for an instrument (and vice-versa). The present invention 
provides a system wherein financial instruments are specified without reference to the 
particular type of processor that will process them, and thus are free to be processed by a 
plurality of processors of different types. See the specification at page 7, lines 12-20, 
which provides an illustrative example of providing three alternate processors for a finan- 
cial "option" instrument. See also the right-hand column of Fig. 7 of the present applica- 
tion (a copy of which is also reproduced in the sheet attached at the end of this paper), 
which provides a graphic illustration of alternative processors for an instrument. 

Laboratory instruments are very different from financial instruments in this re- 
gard. Normally, one would not even want alternative ways to process a laboratory in- 
strument, e.g., alternative ways to set a potentiometer or take a temperature reading. Un- 
surprisingly, Kodosky does not provide any such feature. 

Moreover, it is not just that case that Kodosky is silent with regard to this aspect 
of the present invention; in fact the teachings that Kodosky does contain are entirely anti- 
thetical to the present invention. In Kodosky, there is only one processor per instrument. 
Indeed, there is only one processor in the entire system of Kodosky: see col. 35, lines 30- 
34, which unequivocally states: "there is but one processor on the computer." This cen- 
tral aspect of Kodosky, together with the fact that, as discussed above, the "instrument 
specification" in Kodosky is processor-specific, is completely incompatible with what is 
claimed in claim 21. These aspects render Kodosky inappropriate as part of a combina- 
tion to be applied under 35 U.S.C. § 103 (a). "If proposed modification would render the 
prior art invention being modified unsatisfactory for its intended purpose, then there is no 
suggestion or motivation to make the proposed modification." MPEP 2143.01. Put an- 
other way, Kodosky in its entirety, which structures all processing with reference to a 
single type of processor, "teaches away" from the present invention. See MPEP 2141.02. 

Perhaps the Examiner was led to the conclusion he reached because of the discus- 
sion in Kodosky of the ability to process a plurality of instruments simultaneously. See 
for example col. 36, lines 37-42. While this disclosure may reflect a plurality of instru- 
ments that are handled independently of each other, it plainly says nothing about 
whether the instruments are specified independently of the processor, which, in 
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Kodosky, they are not. The ability per se to process a plurality of instruments is irrele- 
vant to the subject matter actually claimed by claim 21. 

(b) Lack of an "Event Representation." Claim 21 also contains the limitation 
"wherein said representation comprises a static representation and an event representation 
of said instrument." The rejection is based on the assumption that at least one of the ref- 
erences - which according to the Examiner's recitation would be Marshall - discloses an 
"event representation" of a financial instrument. This is incorrect. 

The word "representation" is commonly defined in the present context as some- 
thing that "serve [s] as a specimen, example or instance of the matter being represented 
(Merriam- Webster's Collegiate Dictionary (1 1th ed., 1983)), or that "signifies], symbol- 
ize[s] or embod[ies]" that matter (Compact Oxford English Dictionary (2005)). 

Marshall teaches the representation of financial instruments as "metaphors" - de- 
picted as graphical visual elements - in a virtual world. Marshall also discloses provid- 
ing "a stream of financial information" specifically described as "real time data about fi- 
nancial markets," col. 4, lines 30-32, which information is used at various points in the 
processing described in Marshall. The stream of information constitutes selected data 
"about" financial instruments, essentially, "ticker" data. This information pertains to the 
"metaphors" but does not in itself constitute the "representation" of any instrument. It is 
the "metaphors" of Marshall, and not the market data, that comprise the instrument "rep- 
resentations." 

According to the specification of the present invention, an "event representation" 
of a financial instrument is a time line of inter-related events that is specific to the static 
representation of the instrument, constitutes in its entirety the financial event structure of 
the instrument, and can always be exactly reproduced from the static representation of the 
financial instrument. See specification, pages 9-14. This disclosure from the present 
specification describes a "representation" of a financial instrument, as such term is com- 
monly defined, in terms of the events that occur over the life of the instrument. 

By contrast, nothing disclosed in Marshall, other than the graphical metaphors, 
fits the commonly understood definition of the term "representation." As for the meta- 
phors of Marshall themselves, while they denote financial instruments, they do not depict 
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them in terms of events. Thus, an "event representation" of a financial instrument in ac- 
cordance with claim 21 is lacking from Marshall. 

***** 

The substance of the present rejection was that the teachings of Kodosky suggest 
how to perform different kinds of processing on the event representations of financial in- 
struments as disclosed by Marshall. But as discussed, (a) Kodosky concerns a fundamen- 
tally different form of processing (wherein instruments are specified in a processor- 
dependent manner, as opposed to independently), and (b) Marshall fails to disclose the 
"event representation" of any financial instrument. 

In sum, Applicant submits that, in addition to being nonanalogous, Kodosky is it- 
self irrelevant and that the combination of Kodosky and Marshall fails to disclose two 
separate and distinct claim limitations. 

Accordingly, Applicant respectfully requests that the Examiner reconsider the 
case in light of the foregoing and withdraw the present rejection. The Applicant asks that 
the Examiner reconsider in particular the discussion at pages 6-7 of Applicant's March 2, 
2004 submission and the aforementioned definitions of "static" and "event" representa- 
tions of financial instruments at pages 9-14 of the specification and Fig. 7 of the draw- 
ings. If after such reconsideration the Examiner is still of the view that Kodosky and 
Marshall are pertinent to the present application, Applicant would appreciate the oppor- 
tunity of an interview prior to further action. 
Claims 22-23 and 25-33 

In the preceding remarks, Applicant has primarily addressed claim 21. However, 
since Applicant submits that claim 2 1 is patentable over the cited references, Applicant 
argues on the same basis that the remaining claims, 22-23 and 25-33, each of which is 
dependent from claim 21 and incorporates all of the limitations of claim 21, are pat- 
entable as well. Thus, this submission addresses all of the rejected claims. 
Information Disclosure Statement 

As previously noted, an information disclosure statement ("IDS") remains out- 
standing. Applicant respectfully requests that that the Examiner consider and make of 
record the references cited therein. If necessary, Applicant can provide replacement cop- 
ies. 
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CONCLUSION 



The Applicant earnestly solicits withdrawal of the present rejection and early al- 
lowance of the application. 
Dated: January 20, 2005 




Ronald Abramson 
Registration No. 34,762 
Attorney for Applicant 

HUGHES HUBBARD & REED LLP 
One Battery Park Plaza 
New York, New York 10004-1482 
(212) 837-6404 
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Figure 7 - Event Stream Representation 



Text of Claim 21 (as previously amended) 

A method for processing financial instruments comprising a representation 
of said instrument and at least one processor, wherein said representation 
comprises a static representation and an event representation of said 
instrument and said at least one processor performs said processing by 
acting upon the events of said event representation, and wherein said 
representation is specified independently from said at least one processor. 
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